Add ServiceRegistry to manage manifest loading, directory queries, and
routing decisions with:
- Manifest loading from file, env var, or auto-detection
- On-demand directory loading via DirectoryClient with caching
- Cache TTL support (300s default, configurable)
- Function routing decisions (local vs remote)
- Resource and function metadata access
- Graceful degradation if directory unavailable

Add HTTP client for cross-endpoint function execution with:
- Async/sync job submission to RunPod endpoints
- Async job polling with configurable intervals and timeouts
- Cloudpickle serialization/deserialization of arguments
- Authentication via RUNPOD_API_KEY header
- Error handling and response format handling
- Connection pooling via httpx.AsyncClient
- Async context manager support

Add routing wrapper that intercepts stub execution and determines if
function calls should be executed locally or routed to remote endpoints with:
- Function routing decision based on ServiceRegistry
- Automatic directory loading before routing decisions
- Remote execution via HTTP with proper payload construction
- Class method execution support
- Error handling and logging
- Singleton factory pattern for component reuse

Add ProductionWrapper injection to stubs/registry.py to enable cross-endpoint
routing for LiveServerless and CpuLiveServerless resources.

- Check for RUNPOD_ENDPOINT_ID environment variable (production mode indicator)
- Create and inject wrapper around both stubbed_resource and execute_class_method
- Preserve original behavior when not in production
- Graceful fallback if ProductionWrapper import fails
- No changes to public API or user-facing behavior

This enables transparent cross-endpoint function routing while maintaining
full backward compatibility.

Add comprehensive integration tests covering the full routing flow:
- Local function execution (no remote call)
- Remote function execution via HTTP
- On-demand directory loading
- Error propagation from remote endpoints
- Factory creates complete integrated system

These tests validate the entire stack from ServiceRegistry → ProductionWrapper
→ CrossEndpointClient → HTTP execution, ensuring all components work together.

- Remove CrossEndpointClient HTTP client duplication (~250 lines eliminated)
- Add get_resource_for_function() to ServiceRegistry that returns ServerlessResource
- Modify ProductionWrapper to use ServerlessResource.run_sync() for remote execution
- Delete http_client.py and test_http_client.py (replaced by ServerlessResource)
- Update ProductionWrapper tests to mock ServerlessResource instead of HTTP client
- Add unit tests for get_resource_for_function() in ServiceRegistry tests
- Update integration tests to mock ServerlessResource
- Simplify ServerlessResource import (no circular dependency)
- All 405 tests pass with 65% coverage

Remove unnecessary lazy imports from inside fixture - there's no circular
dependency issue. ResourceManager and SingletonMixin don't create circular
imports when imported at module level.

…ements

Add comprehensive lessons learned from the recent refactoring session:

- Add async thread safety pattern to Async Best Practices section
- Add custom exception hierarchies to Error Handling section
- Expand anti-patterns with URL parsing and unreachable code examples
- Add mock alignment lesson to Testing Requirements
- Create new Configuration Patterns section for constant centralization

These lessons reflect improvements made to the cross-endpoint routing feature:
- Thread-safe async cache with asyncio.Lock
- Custom exception hierarchy (RuntimeError → RemoteExecutionError, SerializationError)
- Robust URL parsing with urllib.parse.urlparse
- Centralized configuration in config.py module
- Test mock alignment with actual API contracts

All examples use consistent GOOD / BAD pattern for clarity.

Add custom exception hierarchy and centralized configuration:

- Create exceptions.py with RuntimeError base and domain-specific exceptions
- Create config.py with centralized constants (timeouts, retries, cache TTL)
- Add asyncio.Lock for thread-safe directory cache in ServiceRegistry
- Improve URL parsing with urllib.parse.urlparse and validation
- Fix JobOutput API mismatch: check error field instead of success attribute
- Add serialization error handling with custom SerializationError
- Improve type hints across runtime modules
- Update tests to align with actual API contracts

Rename DirectoryClient to ManifestClient to better reflect its purpose as
the manifest directory service (endpoint registry) rather than a generic
directory. This addresses PR #129 comment regarding naming clarity.

Changes:
- Rename src/tetra_rp/runtime/directory_client.py to manifest_client.py
- Rename class DirectoryClient -> ManifestClient
- Rename exception DirectoryUnavailableError -> ManifestServiceUnavailableError
- Update all imports and references in:
  - service_registry.py
  - exceptions.py
  - All test files (test_manifest_client.py, test_service_registry.py, test_cross_endpoint_routing.py)

The manifest directory service fetches an endpoint registry that maps
resource_config names to their deployment URLs from the mothership API.

All 581 tests passing. Code coverage: 65.37%.

Create new src/tetra_rp/runtime/models.py with Pydantic-inspired dataclasses:
- FunctionMetadata: Function definition with name, module, async status, HTTP routing
- ResourceConfig: Resource configuration with type, handler, and functions
- Manifest: Top-level manifest with version, project name, function registry, resources

This addresses the PR #129 comment to improve manifest type safety and IDE support.

Changes:
- ServiceRegistry now loads manifests into Manifest objects
- Maintains backward compatibility with dict-based manifests in handler generators
- Updated get_all_resources() and get_resource_functions() to convert to dicts
- Updated HandlerGenerator and LBHandlerGenerator to work with both dict and Manifest
- Updated test fixtures to use attribute access instead of dict access

Manifest.to_dict() allows serialization to JSON, and Manifest.from_dict()
allows deserialization from JSON.

All 581 tests passing. Code coverage: 65.68%.